home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group02b.txt
/
000113_icon-group-sender_Mon Nov 11 19:33:45 2002.msg
< prev
next >
Wrap
Internet Message Format
|
2003-01-02
|
2KB
Return-Path: <icon-group-sender>
Received: (from root@localhost)
by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gAC2XNo03073
for icon-group-addresses; Mon, 11 Nov 2002 19:33:23 -0700 (MST)
Message-Id: <200211120233.gAC2XNo03073@baskerville.CS.Arizona.EDU>
Date: Mon, 11 Nov 2002 14:32:26 -0700
From: Clint Jeffery <jeffery@cs.nmsu.edu>
To: art.eschenlauer@sufsys.com
CC: rhm@cdepot.net, gmt@cs.arizona.edu, icon-group@cs.arizona.edu
Subject: Re: Cygwin (RE: UNIX tools on Windows)
Errors-To: icon-group-errors@cs.arizona.edu
Status: RO
[Art puts in a good plug for Cygwin]
I don't believe this interpretation of mingw32 is entirely complete.
In contrast with cygwin which uses one or more big UNIX compatibility DLLs,
mingw32's goal is to produce "native" Windows applications that link to the
DLL's that come with Windows. It is true that any UNIX compatibility
layered on top of Win32 in that case is statically linked, but since its
goal is for gcc to run well under Windows, rather than to make it into a UNIX,
it may produce executables that are more attractive for some applications
than does a cygwin-based UNIX-compatible Windows build. For example, you
can deliver a .exe that works without having the customer install Cygwin.
Having said all that, I am all in favor of UNIX-compatibility tools on
Windows, and all in favor of supporting Cygwin in our source code. I only
wish Microsoft had had the minimal sense of technical vision it would have
taken to make Windows a real UNIX with real X11 in the first place.
Apple has pretty much achieved this...
Clint